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RESPONSE TO OFFICE ACTION 

Sir: 

No fees are believed to be required. If, however, any fees are required, I authorize the Commissioner 
to charge these fees which may be required to IBM Corporation Deposit Account No. 09-0457. 

A one-month extension of time is believed to be necessary. I authorize the Commissioner to charge 
the one-month extension fee of $120.00 to IBM Corporation Deposit Account No. 09-0457. No additional 
extension of time is believed to be necessary. If, however, an additional extension of time is required, the 
extension is requested, and I authorize the Commissioner to charge any fees for this extension to IBM 
Corporation Deposit Account No. 09-0457. 

In response to the Office Action of February 6, 2007, please amend the above-identified 
application as follows: 

Amendments to the Specification begin on page 2 of this paper. 

Amendments to the Claims are reflected in the listing of claims which begins on page 4 of this paper. 
Amendment to the Drawings begin on page 7 of this paper and include an attached replacement sheet 
and an annotated sheet showing changes. 
Remarks/Arguments begin on page 8 of this paper. 
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Amendments to the Specification: 



Please delete the paragraph beginning on page 4, line 1 and replace with the following: 

Referring now to the drawings in detail, wherein like reference numerals indicate like 
elements throughout, Figure 1 illustrates a computer system generally designated 10 according to 
the present invention. System 10 comprises a client 12, a server computer 14 and an intervening, 
known communication system 16. Client 12 can be a desktop or lap top personal computer, 
PDA, cell phone, electronic instrument/tool, equipment, etc. In the illustrated embodiment, 
client 12 includes a CPU 20, an operating system 22 executing on the CPU 20, and an 
application 24 executing on the operating system and CPU. Application 24 can be a browser, 
e-mail agent or connectivity application. Server 14 comprises one or more CPUs 30, an 
operating system 32 executing on CPU 30, and server software 34 executing on operating system 
32 and CPU 30. Server software 34 can be an e-mail service web site or connectivity software. 
The communication system 16 comprises components such as electrical or optical transceivers 
and associated electrical or optical cabling, wireless communication transceivers, and/or 
networking hardware. Various, known communication protocols can be used for the 
communication between the client 12 and the server 14 such as SOAP, TCP/IP, HTTP, HTML, 
FTP, or SMTP. 

Please delete the paragraph beginning page 12, line 25 and replace with the following: 

Referring again to decision 1 1 1, if the current message includes a compressed header, i.e. a 
UID and changes, if any, to the previously cached header referenced by the UID, then server software 34 
recreates the full header (step 120). The server software 34 recreates the full header by reading from 
cache 56 the previously cached header referenced by the UID in the current compressed message header, 
and then modifying the previously cached header with the changes, if any, in the current message header 
of the compressed message. Next, the server software combines the recreated, full header with the current 
payload to form a full, current message (step 122). Then, server software assigns a new UID for the 
recreated, full current header and caches the recreated, full current header (step 124). Then, server 
software 34 handles and responds to the recreated, full current message in the prior art manner, except 
that the server software 34 will include the UID in the response (step 115). The UID represents the 
recreated, full current header (if a compressed header was furnished by the client in step 100) or the UID 
for the full current header (if the full header was furnished by the client in step 100) (step 130) . The server 
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software 34 also returns an acknowledgment that the message was handled. For subsequent messages, the 
client 12 can opt to use this UID (or other UID previously or subsequently retuned by server 14) to 
compress the respective message from the client. Compression of the messages will reduce the 
bandwith/transmission time requirement for the messages sent from the client to the server. As noted 
above, if the server software 34 is not willing to support header compression for this type or any type of 
message from client 12, then the server software 34 does not return a UID in step HO [[130]], and instead 
returns a simple acknowledgment that the message was handled. 
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Amendments to the Claims: 

This listing of claims will replace all prior versions, and listings, of claims in the application: 

Listing of Claims; 

1-2. (Cancelled) 

3. (Currently Amended) A method for processing message headers by a first data processing 
system, said method comprising the steps of: as s e t forth in claim 1 whc - roin tho motiving r.tap comprises 

receivin g, from a second data processing system, a message including a compressed header 
comprising an identifier to a reference, uncompressed header and changes from said reference header , and 
in response, 

determining impact of header compression on performance, and 
if favorable, supporting the header compression for subsequent communications, and 
if unfavorable, refusing to support the header compression for the subsequent communications, 
wherein if the impact of header compression on performance is determined to be favorable, then handling 
said message by forming another uncompressed header based on said reference header and said changes, 
and returning another identifier for said another uncompressed header to the second data processing 
system, said another identifier being assigned by the first data processing system for use in another 
compressed header generated by the second data processing system , 

4-9. (Cancelled) 

10. (Currently Amended) A method for compressing message headers by a first data processing 
system , said method comprising the steps of: 

receivin g, from a second data processing system, a message including a compressed header, 
wherein said compressed header includes an identifier to a reference header and changes relative to said 
reference header ; 

determining impact of header compression on performance, and 
if favorable, handling said message, and 
if unfavorable, refusing to handle said message,, 

wherein if the impact of header compression on performance is favorable, further comprising the 
step of reconstructing said message with an uncompressed header based on said reference header and said 
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changes, befo re the step of handling said message, and returning another identifier for said uncompressed 
header to the second data processi ng system, said another identifier being assigned by the first data 
processing system for use in another compressed header generated by the second data processing system . 

11-12. (Cancelled) 

13. (Currently Amended) A method for compressing message headers, said method comprising the 
steps of: 

a server receiving a message including a compressed header; 

said server determining whether said server has sufficient memory or storage to support header 
compression, and 

if so, handling said message, and 

if not, refusing to handle said message or notifying a sender of said message that said 

server will not support the header compression for subsequent messages, 

wherein compression for said compressed header requires that said server store a reference 

header, and wherein said compressed header comprises an identifier to a reference, uncompressed header 

and changes relative to said reference header, and if said server has sufficient memory or storage to 

support the header compression, further comprising the steps of: 

forming an uncompressed header based on said compressed header: and 

returning to a sender of said message another identifier of said uncompressed header to be used 

for a subsequent compressed header, said another identifier being assigned by the server . 

14-17. (Cancelled) 

1 8. (Currently Amended) A method as sot forth in claim 1 6 A method for compressing message 
headers by a first data processing system, said method comprising the steps of: 

receiving, from a second data processing system, a message including an uncompressed header, a 
message including a compressed header or a request to support header compression, and in response. 

determining if there is sufficient storage available to support the header compression, and 
if so, supporting the header compression for subsequent communications, and 
if not, refusing to support the header compression for the subsequent communications , 

wherein said compressed header includes an identifier to a reference, uncompressed header and 
changes relative to said reference header, and the receiving step comprises the step of receiving [[a]] the 
message including a compressed header, and if there is the sufficient storage available to support the 
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header compression, then generating another uncompressed header based on said reference header and 
said changes and returning another identifier for said generated another uncompressed header to the 
second data processing system to be used for a subsequent compressed header, said another identifier 
being assigned by the first data processing system . 

19. (Cancelled) 
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Amendments to the Drawings: 

Figure 1 has been amended to add reference identifiers 10, 16 and 30 as requested by the Examiner. 

Attachments: 1 Replacement Sheet 
1 Annotated Sheet 



Page 7 of 14 
Weller- 10/656,946 



REMARKS/ARGUMENTS 



Amendments were made to the specification to correct errors and to clarify the specification. No 
new matter has been added by any of the amendments to the specification. 

Claims 3, 10, 13 and 18 are pending in the present application. Claims 3, 10, 13 and 18 have 
been amended, and Claims 1, 2, 4-9, 11, 12, 14-17 and 19 have been cancelled, herewith. 
Reconsideration of the claims is respectfully requested. 

I. Drawings 

The drawings were objected to as not containing reference signs 10, 16, 30 and 130. Applicants 
are submitting concurrently herewith a replacement sheet for Figure 1 that includes reference signs 10, 16 
and 30. As to missing reference sign 130, Applicants are amending the Specification herewith to modify 
this reference in the Specification, in order to match an existing reference sign (1 10) in the drawings. 

Therefore, the objection to the drawings has been overcome. 

II. Specification 

The specification was objected to, with the Examiner noting the reference character "CPU 30" 
appears to use an incorrect number. Applicants believe the above described change being made to Figure 
1 corrects this problem, as reference number '23' for the CPU is being changed to '30'. 

Therefore, the objection to the specification has been overcome. 

III. Claim Objection 

Several claims were objected to as containing improper antecedent basis. Applicants have 
amended the claims in accordance with the Examiner's suggested changes. 
Therefore, the objection to the claims has been overcome. 

IV. 35 U.S.C. S 101 

Claims 1-19 stand rejected under 35 U.S.C. § 101 as being directed towards non-statutory subject 
matter. This rejection is respectfully traversed. 

Claims 1 and 2 have been cancelled herewith, without prejudice or disclaimer, for possible 
pursuant in a continuation application. 

Claim 3 has been amended to be in independent form. Claim 3 has also been amended to include 
the features of dependent Claims 4 and 5. 
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With respect to the rejection of Claims 1-5, the Examiner states that no tangible output or result is 
provided that would be observed by a user. Applicants urge error in such user-observation test, as there is 
no requirement that a tangible result be observed by a user in order for a claim to comply with 35 U.S.C. 
§ 101. While abstract ideas, natural phenomena, and laws of nature are not eligible for patenting, 
methods and products employing abstract ideas, natural phenomena, and laws of nature to perform a real- 
world function may well be, MPEP 2106(IV)(C). In evaluating whether a claim meets the requirements 
of section 101, the claim must be considered as a whole to determine whether it is for a particular 
application of an abstract idea, natural phenomenon, or law of nature, and not for the abstract idea, natural 
phenomenon, or law of nature itself, MPEP 2106(rV)(C). Claim 3 is not directed to a mere abstract idea, 
natural phenomenon, or law of nature, but instead is directed to a method (which is a process, and 
processes are one of the four explicitly enumerated classes of statutory subject matter under 35 USC 101), 
and such method provides a practical application in that it provides improved communication capabilities 
between two computer systems, through the use of header compression techniques. The Examiner states 
that the claims are merely directed to 'moving back and forth of data from client to server with no output 
or result'. Applicants urge that to the contrary, the fact that data is processed and moved from one system 
to another is in itself an output, the output being the data that is moved between these two system 
components - which is a useful, concrete and tangible result that provides a practical utility, and therefore 
Claim 3 does not fall within a judicial exception of abstract idea, natural phenomenon, or law of nature'. 
Accordingly, since Claim 3 is directed to a specifically enumerated class of statutory subject matter (a 
'process') and does not fall within ajudicial exception, such claim complies with both 35 USC 101 and 
the MPEP requirements spelled out in section 2106. In addition, there is no user-observance requirement 
that must be met, as alleged by the Examiner in rejecting such claim. 

Further with respect to Claim 3, such claim recites receiving a message including a compressed 
header, and this compressed header is an additional useful, concrete and tangible result that provides a 
practical application and does not fail within ajudicial exception. 

Further with respect to Claim 3 (which was amended to include the features of dependent Claims 
4 and 5), such claims recites forming another compressed header, and this another compressed header that 
is formed is an additional useful, concrete and tangible result that provides a practical application and 
does not fail within ajudicial exception. 



1 The Examiner should also consult Claim 1 of the presently cited Birdwell reference (US 6,032,197) 
used in the current 35 USC 103 rejection to see that the exchange of data between two systems is 
patentable. Numerous data protocols/handshakes that are directed to the exchange of data between 
systems are also patentable, as evidenced by Claim 1 of US Patent 7,222,152; Claim 1 of US Patent 
7,177,628; etc. 
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Claims 6-9 have been cancelled herewith, without prejudice or disclaimer, for possible pursuant 
in a continuation application. 

Claims 11-12 and 16-17 have been cancelled herewith, without prejudice or disclaimer, for 
possible pursuant in a continuation application. 

With respect to Claims 10, 13 and 18, Applicants initially traverse for similar reasons to those 
given above with respect to Claim 3, and urge (i) these claims are directed to a specifically enumerated 
class of statutory subject matter (a 'process') and (ii) these claims do not fall within a judicial exception. 
Accordingly, such claims comply with both 35 U.S.C. § 101 and the MPEP requirements spelled out in 
section 2 106. In addition, there is no user-observance requirement that must be met, as alleged by the 
Examiner in rejecting such claims. Thus, it is urged that these claims have been erroneously rejected 
under 35 U.S.C. § 101. 

Further with respect to Claim 13 (which has been amended to recited features of dependent 
Claims 14 and 1 5), such claim explicitly recites a server receiving a message including a compressed 
header, and therefore does not fail within a judicial exception. 

Further with respect to Claims 18, such claim recites receiving a message including a compressed 
header, and this compressed header is an additional useful, concrete and tangible result that provides a 
practical application and does not fail within a judicial exception. 

Further with respect to Claim 18 (which was amended to include the features of Claim 19), such 
claim recited returning an identifier for a generated uncompressed header, and this identifier and the 
generated uncompressed header are both useful, concrete and tangible results that provides a practical 
application and do not fail within a judicial exception. 

Therefore, the rejection of Claims 1-19 under 35 U.S.C. § 101 has been overcome. 

V. 35 U.S.C. § 103. Obviousness 

Claims 1-12 stand rejected under 35 U.S.C. § 103 as being unpatentable over Birdwell (U.S. 
Patent No. 6,032,197) in view of Chambers (U.S. Patent No. 5,426,779). This rejection is respectfully 
traversed. 

Claims 1 and 2 have been cancelled herewith, without prejudice or disclaimer, for possible 
pursuant in a continuation application. 

With respect to Claim 3, such claim has been amended to be in independent form, and also 
amended to include the features previously recited in dependent Claims 4 and 5. As amended, such claim 
recites "wherein if the impact of header compression on performance is determined to be favorable, then 
handling said message by forming another uncompressed header based on said reference header and said 
changes, and returning another identifier for said other uncompressed header to the second data 
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processing system, said another identifier being assigned by the first data processing system for use in 
another compressed header generated by the second data processing system". None of the cited 
references teach or suggest the conditional returning of an identifier based upon whether or not the 
impact of header compression on performance is determined to be favorable. In rejecting this claimed 
feature, the Examiner cites Birdwell's teaching at col. 6, lines 11- 20 and col. 2, line 66 - column 3, line 
6. In is urged that the Birdwell header index value references a memory location at a destination client, 
and in particular is used to reference an entry in a header table at the destination client of where a header 
is (or will be) stored in the destination client (Birdwell col. 6, lines 1 1-20. There is no teaching or 
suggestion that the data processing system that receives a message (i.e. the Birdwell destination client) 
itself returns an identifier for use in a compressed header. The Birdwell header index value is not 
described as being returned to anything, but instead is used internally within Birdwell's destination client. 

Still further, this returning of an identifier is conditioned upon whether or not the impact of 
header compression on performance is determined to be favorable. In rejecting the 'performance impact' 
aspect of Claim 3, the Examiner cites Chambers as teaching 'the general concept of checking on the 
outcome of compression'. Applicants urge that Claim 3 is not merely directed to the general concept of 
checking on the outcome of compression, but instead recites specific operational steps the conditionally 
occur based upon a header compression impact determination. This is different from the teachings of 
Chambers for several reasons. First, Claim 3 is not merely directed to a general performance 
determination regarding compression, as alleged to be taught by Chambers, but instead is specifically 
directed to performance implications pertaining to header compression (per Claim 3, 'determining impact 
of header compression on performance'). None of the cited references teach or suggest any type of 
performance determination with respect to header compression. Secondly, Chambers describes an after- 
the-fact check on the compression results that exist after actually performing compression. This is done 
since some attempts at compression actually result in a larger file than the file size that existed prior to 
compression (Chambers col. 7, lines 35-40). Accordingly, Chambers requires a check be done after-the- 
fact (after performing the compression) due to this compression anomaly. In contrast, per the features of 
Claim 3, the compression suitability is done before-the-fact - i.e. before attempting the operations that 
subsequently occur if it is determined before-the-fact that the impact of header compression on 
performance is determined to be favorable. Thus, Chambers does not teach or suggest any type of before- 
the-fact header compression impact determination that is then used to conditionally perform the particular 
operations as claimed. Further yet, the Chambers (after-the-fact) compression suitability determination 
does not result in any type of conditional returning of an identifier based upon whether or not the impact 
of header compression on performance is determined to be favorable. Claim 3 expressly recites "wherein 
if the impact of header compression on performance is determined to be favorable, then handling said 
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message by forming another uncompressed header based on said reference header and said changes, and 
returning another identifier for said another uncompressed header to the second data processing system, 
said another identifier being assigned by the first data processing system for use in another compressed 
header generated by the second data processing system". Thus, it is further urged that the Chambers 
reference does not overcome the teaching/suggestion deficiencies identified above with respect to the 
conditional identifier return and the teachings of the cited Birdwell reference. 

Applicants further show that notwithstanding the fact that the combined teachings of the cited 
references do not teach or suggest the conditional identifier return feature, there would also not have been 
any motivation or other reason to modify such teachings to include this missing claimed feature. As to 
the Birdwell reference, such system is directed to a unidirectional broadcast system where data is only 
transmitted in one direction, and not bi-directionally (Birdwell col. 2, lines 6-9; col. 3, lines 65 - 67). 
Thus, there is no mechanism to provide any type of 'return path' to return such an identifier (Birdwell col. 
4, lines 1-2). Still further, Birdwell requires that the 'compressing' processor provide an identifier for use 
by a decompressing processor (Birdwell col. 3, lines 1-25), which is in effect just the opposite of what is 
recited in the claims - where the decompressing processor assigns an identifier to the decompressed data 
and then returns this identifier to the other processor for subsequent use. Due to the exactly opposite 
functions being performed with respect to the identifier's creation/assignment, a person of ordinary skill 
in the art would not have been motivated to essentially re-architect the entire system to switch the roles of 
the compressing device/computer and the decompressing device/computer as such change would in 
essence eviscerate the entire teachings and desires of Birdwell - which is particularly evident when 
viewed in light of Birdwell's unidirectional broadcast system which has no mechanisms for a recipient of 
a compressed message (decompress-side system) to transmit or return an identifier back to the compress- 
side system. Birdwell explicitly acknowledges that bi-directional data transfer techniques do not work in 
unidirectional systems (col. 1, line 65 - col. 2, line 3). As to the cited Chambers reference, such reference 
similarly does not contemplate any need or reason to return a header identifier to another system (e.g. the 
one performing compression), as the system for which the performance impact is determined to be 
appropriate or not is the same system that performs the compression, and therefore there would be no 
need or reason to conditionally return a header identifier to another system for use in another compressed 
header, as it is the same Chambers system that performs the (after-the-fact) compression suitability check, 
that also performs the compression - and hence there would be no need or reason to provide information 
to another system to assist in compression processing. Thus, in addition to the combined teachings 
having missing claimed features (as described in detail above), it is further urged that a person of ordinary 
skill in the art would not have been motivated to modify such combination to include such missing 
claimed features. 
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Accordingly, (1) as none of the cited references teach or suggest the claimed conditional return of 
a header identifier depending upon whether or not header compression is determined to have a favorable 
impact on performance, and (2) there would have been no reason or motivation to modify such teachings 
to provide that above described missing claimed features, it is urged that amended Claim 3 is not obvious 
in view of the cited references. 

Applicants traverse the rejection of Claims 10 for similar reasons to those given above with 
respect to Claim 3. 

Therefore, the rejection of Claims 1-12 under 35 U.S.C. § 103 has been overcome. 

VI. 35 U.S.C. § 103, Obviousness 

Claims 13-14 and 16-19 stand rejected under 35 U.S.C. § 103 as being unpatentable over 
Birdwell (U.S. Patent No. 6,032,197) in view of Culbert (U.S. Patent No. 5,696,926). This rejection is 
respectfully traversed for similar reasons to those given above with respect to Claim 3, as it is urged that 
the additional cited Culbert reference does not overcome the teaching/suggestion deficiencies identified 
above with respect to Claim 3. 

Therefore, the rejection of Claims 13-14 and 16-19 under 35 U.S.C. § 103 has been overcome. 

VII. 35 U.S.C. § 103, Obviousness 

Claim 15 stands rejected under 35 U.S.C. § 103 as being unpatentable over Birdwell (U.S. Patent 
No. 6,032,197) in view of Chambers (U.S. Patent No. 5,426,779), and further in view of Culbert (U.S. 
Patent No. 5,696,926). This rejection is respectfully traversed for similar reasons to those given above 
with respect to Claim 3, as it is urged that the additional cited Culbert reference does not overcome the 
teaching/suggestion deficiencies identified above with respect to Claim3. 

Therefore, the rejection of Claim 15 under 35 U.S.C. § 103 has been overcome. 
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It is respectfully urged that the subject application is patentable over the cited references and is 
now in condition for allowance. The Examiner is invited to call the undersigned at the below-listed 
telephone number if in the opinion of the Examiner such a telephone conference would expedite or aid the 
prosecution and examination of this application. 



DATE: June 6. 2007 

Respectfully submitted, 



/Wayne P. Bailey/ 



Wayne P. Bailey 
Reg. No. 34,289 
Yee & Associates, P.C. 
P.O. Box 802333 
Dallas, TX 75380 
(972)385-8777 
Attorney for Applicant 
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